home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-04-16 | 1.6 KB | 38 lines | [TEXT/GEOL] |
- Item forwarded by A33 to A34
-
- Item 6389115 9-April-90 22:23DST
-
- From: UK0392 EHN & DIJ Oakley,IDV
-
- To: MACAPP.ADMIN Design Methodology,Joel Norvell,VCA
-
- cc: MACAPP.TECH$ MacApp Technical
-
- Sub: ReReRe Abbs Plc in McAp
-
- Joel,
-
- 1. Try a symbol dump in MacsBug - I am using the latest version, and all I can
- ever see is a list with truncated names.
- 2. I am sure that I can remember the MacApp debugger having the same limitation
- in one of its symbol-listing modes, but perhaps that was with 1.1.1.
- 3. It is not uncommon, though, for there to be an upper limit on symbol names
- in debuggers, if for no other reason than saving memory - even if this is 31 or
- more characters, it is still a limit which can be exceeded easily.
- 4. It also takes a finite length of time to type source - the fewer chars
- [permissible :-)] the better, and particularly for names used frequently, the
- smaller the source files (and symbol files) too.
-
- As regards clarity, I would beg to suggest that there is nothing in my 'rules'
- which should ever mask clarity or meaning. A resulting name might be
- "DisposTxtHdle", which under Curtis' rules would have to be
- "DisposeTextHandle", an extra 4 characters without (to me at least) any
- apparent difference in meaning. I think it is consistency and obviousness
- which is paramount, rather than simply attacking minimal contractions - that
- was the object of my rules, as opposed to Curtis' which placed
- "1) Don't use abbreviations unless you can save 4 or 5 characters."
- first.
-
- Regards, Howard.
-
-